Давно мы что-то не писали про сравнения платформ виртуализации, которые, зачастую, сильно попахивают предвзятостью и переворачиванием фактов. Но на этот раз мы бы хотели отметить одно из немногих достаточно независимых сравнений "Enterprise Hypervisor Comparison", в котором автор сам явно указывает, что идеального продукта для любой инфраструктуры нет. Особенно если брать в расчет стоимость решения.

В документе рассмотрены следующие платформы виртуализации в различных аспектах функциональности, необходимой для среднего и крупного предприятия:

• VMware vSphere 5.1
• Microsoft Windows/Hyper-V Server 2012
• Red Hat Enterprise Virtualization 3.1 (на данный момент в стадии беты)

Для Windows Server 2012 и Hyper-V данные приведены с учетом Microsoft System Center 2012 Service Pack 1, который еще не выпущен, о чем в документе сделана специальная пометка. Надо отметить, что автор рассматривал только полнофункциональные версии продуктов и не рассматривал их бесплатные версии.

В целом, получилось неплохое сравнение, которое, однако, нельзя рассматривать как единственный источник информации при выборе решения.

В наш центр компетенции приехала большая куча коробок с логотипами и защитными марками CISCO. Наконец-то мы смогли вживую увидеть, как выглядят сервера CISCO UCS. Ниже представляем фотоотчет процесса распаковки и осмотра блейд-серверов. Для нас это событие знаковое: 12 сентября этого года мы получили специализацию CISCO Advanced Unified Computing Technology, и теперь, учитывая золотой статус NetApp и Enterprise VMware, мы получили возможность собрать полноценный FlexPod. Напомним основные элементы архитектуры Cisco UCS...

Для мониторинга инфраструктуры виртуализации VMware vSphere зачастую используется протокол SNMP (например, через серверы Open NMS , CACTI , PRTG и т.п.). До версии VMware vSphere 5.1 поддерживались только версии 1 и 2 протокола SNMP. С выпуском версии 5.1 была добавлена поддержка третьей версии этого протокола (SNMPv3), который имеет множество улучшений, в основном касающихся безопасности.

Также в процессе настройки SNMP на хостах ESXi можно выбрать способ приема агентом сообщений: от IPMI-сенсоров (как в прошлых версиях ESXi) или CIM-индикаторов. Кроме того, можно фильтровать отсылаемые на сервер мониторинга SNMP-сообщения.

Для управления протоколом SNMP в консоли ESXi можно использовать следующее пространство имен:

esxcli system snmp

Для настройки протокола SNMP версий 1 и 2 нужно сделать 4 простых шага:

1. Установить community string (по сути, это пароль) командой:

esxcli system snmp set –communities public

2. Установить сервер мониторинга (SNMP target), который включает адрес и порт, а также community string:

esxcli system snmp set –targets server.domain@161/public

3. Включить сервис SNMP на хосте ESXi:

esxcli system snmp set –enable true

4. Протестировать конфигурацию:

esxcli system snmp test

Для того, чтобы протестировать SNMP со стороны таргета можно использовать команду (для версии 2):

snmpwalk -v2c -c public esxserver.domain

Для настройки протокола SNMP версии 3 нужно сделать 8 шагов (не все обязательны):

1. Выставляем Engine ID для SNMP-агента (ID - это шестнадцатиричное значение от 5 до 32-х разрядов длиной):

esxcli system snmp set –engineid 766d77617265

2. Выставляем протокол аутентификации (SHA1, MD5 или none):

esxcli system snmp set –authentication SHA1

3. Устанавливаем протокол шифрования:

esxcli system snmp set –privacy AES128

4. Если мы включили протоколы шифрования в шагах выше, то нужно сгенерировать хэши для паролей аутентификации и шифрования (опция -r означает, что пароли вводятся прямо в команде):

esxcli system snmp hash -r -A pass1 -X pass2

5. Настраиваем пользователя SNMP, указывая хэши, полученные в предыдущей команде (user - ваш пользователь):

esxcli system snmp set –users user/f9f7311379046ebcb5d134439ee5b7754da8a90f/d300f16eec59fb3b7ada7844ff764cbf4641fe5f/priv

6. Устанавливаем SNMP-таргет:

esxcli system snmp set –v3targets server.domain@161/user/priv/trap

7. Включаем SNMP:

esxcli system snmp set –enable true

8. Тестируем настройки:

esxcli system snmp test

Точно так же, как и для версий 1 и 2, со стороны сервера можно проверить работоспособность настроек SNMP, указав введенные ранее пароли:

snmpwalk -v3 -u user -l AuthPriv -a SHA -A pass1 -x AES -X pass2 esxserver.domain

Все вышеперечисленное можно сделать и через vSphere CLI (нужно ставить на отдельную машину) в интерактивном режиме с помощью скрипта vicfg-snmp.pl:

Если вам не хочется заморачиваться с установкой vSphere CLI, то можно использовать скрипт configureSNMPv3.sh, с помощью которого настройка происходит легко и просто:

Недавно компания VMware разослала своим клиентам и партнерам письмо, в котором сообщалось об окончании поддержки линейки VMware vSphere 4.x, построенной, в том числе, на базе "толстого" гипервизора VMware ESX. Теперь эта новость доступна на официальном сайте VMware.

Дата окончания продаж vSphere 4.x: 15 августа 2013 г.

В связи с этим пользователям до 15 августа следующего года рекомендуется создать или сохранить резервную копию соответствующих дистрибутивов и сформировать необходимые лицензионные ключи на портале My VMware для поддержки или расширения сред на базе гипервизора vSphere ESX версии 4.x или vMA версий 1 и 4. Эти операции необходимо выполнить до 15 августа 2013 г. Компания VMware не будет предоставлять никакие двоичные файлы (дистрибутивы, утилиты и т.п.) и лицензионные ключи для гипервизора vSphere ESX 4.x и для vMA версий 1 и 4 после 15 августа 2013 г.

Касательно поддержки (SnS) и жизни после 15 августа:

• Жизненный цикл поддержки гипервизора vSphere ESX 4.X и vMA.
  Датой окончания поддержки остается 21 мая 2014 г. Подробнее о жизненном цикле поддержки VMware.
  
  
• Возможность использования заказчиками гипервизора vSphere ESX 4.x или vMA версий 1 и 4 после 15 августа 2013 г.
  Заказчики сохраняют возможность использования лицензированных копий продукта после даты окончания продаж и даты окончания поддержки. Тем не менее они не смогут загружать дистрибутивы и формировать новые лицензионные ключи после даты окончания продаж и получать техническую поддержку и подписку после даты окончания поддержки.
  
  
• Продажа и поддержка vSphere ESXi 4.X — БЕЗ изменений.
  
  
• Продажа vMA 4.1, 5 и 5.1 и поддержка всех версий — БЕЗ изменений.

Не так давно мы писали о планируемом VMware продукте VMware vCenter Multi-Hypervisor Manager (MHM), который позволяет управлять серверами и виртуальными машинами на платформе Hyper-V. На днях компания VMware выпустила первую версию плагина Multi-Hypervisor Manager, который, конечно же, не поддерживает Hyper-V 3.0 в Windows Server 2012 (конечно же - потому что VMware в последнее время взяла моду выпускать продукты без поддержки последних версий). Однако, вроде бы, в скором времени обещают версию и под новый Hyper-V.

VMware vCenter Multi-Hypervisor Manager поставляется в виде плагина к "толстому" клиенту vSphere Client (Web Client не поддерживается), который предоставляет доступ к дереву объектов Microsoft Hyper-V на базе следующих ОС:

• Microsoft Hyper-V Server 2008
• Microsoft Hyper-V Server 2008 R2

Напомним, что, согласно архитектуре решения, MHM имеет не только клиентскую часть, но и серверный компонент:

Для установки серверной части потребуются следующие вычислительные ресурсы:

• 2 CPU на частоте 2 ГГц или более
• 4 ГБ памяти
• 1 ГБ дискового пространства
• Сетевой адаптер

Между всеми компонентами данной архитектуры осуществляется безопасная коммуникация по HTTPS.

Надо отметить, что серверная часть Multi-Hypervisor Manager - это Windows-приложение, поэтому если вы используете, например, виртуальный модуль VMware vCenter Server Appliance (vCSA), то придется устанавливать MHM на отдельную виртуальную или физическую Windows-машину и связывать его с сервисом vCenter. И да, надо отметить, что:

vCenter Multi-Hypervisor Manager is a fully-supported vCenter Server feature. VMware provides support for all vCenter Multi-Hypervisor Manager or vSphere related issues

Возможности vCenter Multi-Hypervisor Manager 1.0 для хостов Hyper-V:

• Добавление/удаление хостов Hyper-V в окружение vCenter
• Информация о конфигурации хостов Hyper-V (processor, memory, network)
• Создание/удаление виртуальных машин на Hyper-V
• Удаленная консоль как к самим хостам Hyper-V, так и к виртуальным машинам
• Простейшие операции по управлению питанием хостов и виртуальных машин (power off, power on, suspend, shut down guest и reset)
• Изменение настроек виртуальных машин: память, vCPU, диски, сетевые адаптеры и прочее виртуальное "железо"
• Отображение задач для хостов Hyper-V и виртуальных машин на общей панели задач и событий vSphere Client
• Интегрированная авторизация с vCenter, а также поддержка механизма пользователей и ролей

Скачать VMware vCenter Multi-Hypervisor Manager 1.0 можно по этой ссылке. Есть еще FAQ в KB 2037570.

Как знают пользователи решения для виртуализации настольных ПК VMware View, в данном решении для доступа пользователей к своим десктопам используется протокол PCoIP, разрабатываемый компанией Teradici при поддержке VMware. Мы уже писали о настройках протокола PCoIP, а также утилите, позволяющей их регулировать из графического интерфейса, а сегодня расскажем о калькуляторе для расчета необходимой полосы пропускания PCoIP.

Называется этот калькулятор "PCoIP Protocol Bandwidth Planning Calculator", он доступен для загрузки по этой ссылке (в форму можно забить ерунду - подтверждения через почту не потребуется).

Интересно то, что это уже четвертая версия калькулятора PCoIP, которая выглядит весьма навороченно и серьезно. Для планирования доступен как корневой датацентр компании, так и филиалы, для которых рассчитывается необходимая суммарная пропускная способность, которую нужно обеспечить при внедрении решений для виртуализации ПК.

Помимо, собственно, калькулятора в документе приведен детальный план по достижению оптимальной конфигурации инфраструктуры доступа VMware View. На последнем листе xls-файла доступна таблица с рекомендованными полосами пропускания, которые нужно выделять для различных типов нагрузок в виртуальных ПК, а также настройками параметров тонкой настройки протокола PCoIP:

Это краткая версия таблицы - при необходимости ее можно развернуть и получить, например, такую картинку.

Не так давно мы писали о политиках ценообразования для облачной IaaS-платформы Microsoft Azure, которая позволяет брать виртуальные машины с Microsoft Windows или Linux в аренду для организаций (сейчас находится в стадии Preview - что-то вроде бета-версии). Как известно, у Microsoft под цели Azure выделено несколько датацентров (каждый из которых дублирован в соответствующем регионе):

• US North Central – Chicago, IL
• US South Central – San Antonio, TX
• West Europe – Amsterdam
• North Europe – Dublin
• East Asia – Hong Kong
• South-East Asia – Singapore

Есть даже интересное видео про то, как эти датацентры устроены, и как они работают:

На их строительство и ввод в эксплуатацию было затрачено аж 2,5 миллиарда грина. Скоро будет построено еще 13 датацентров, что намекает на то, что Microsoft серьезно рассчитывает получить немалую прибыль с облачного бизнеса.

Однако тут обнаруживаются интересные вещи, касающиеся доступности IaaS-сервисов Azure. На конференции Microsoft TechEd, проходившей в июне 2012 года, были показаны следующие показатели доступности в рамках SLA для пользователей Microsoft Azure:

Как мы видим, для одиночных ВМ гарантируемый показатель доступности на 0,05 ниже, чем для тех приложений, ВМ которых дублированы (а доступ осуществляется, например, через балансировщик). Это ок.

А вот, что было показано уже в октябре 2012 года на конференции Build (пруф на 36-й минуте этого видео):

Куда делся SLA для виртуальной машины, архитектура приложения в которой не подразумевает дублирование на уровне нескольких экземпляров ВМ? Его просто нет. SLA исчез. Это значит, что такая машина Azure может простаивать не 8,75 часов в год, а все 875 часов, и Microsoft ничего за это не будет. Вот такие вот "облака" у Microsoft.

Оказывается, еще в сентябре компания VMware обратила внимание пользователей на один интересный продукт - VMware vCenter Support Assistant. Он призван помочь пользователям в сборе и отправке диагностических данных о своей виртуальной инфраструктуре, а также обращении в техническую поддержку.

Продукт будет представлять собой виртуальный модуль (Virtual Appliance) для VMware vCenter и позволит грамотно оформлять Support Request'ы, а также взаимодействовать с инженерами техподдержки VMware в удобном интерфейсе. Сейчас он находится в стадии бета-тестирования.

vCenter Support Assistant позволит оформлять запросы в техподдержку не только для VMware vSphere, но для любого другого продукта VMware, для которого куплена поддержка на базе SnS или по инцидентам. На данный момент поддерживаются версии VMware vSphere 5.1, 5.0 и 4.1.

После установки, VMware vCenter Support Assistant появится как плагин к vSphere Client:

Дальше логинимся:

и создаем Support Request:

После детального описания проблемы (суть, критичность, категория, статьи KB) можно собрать и прикрепить диагностическую информацию:

После того, как запрос в техподдержку будет сформирован, а необходимые логи и конфиги загружены, можно посмотреть статус своего обращения:

В целом, должна быть удобная штука, особенно для больших компаний, где много администраторов, виртуальных машин и, соответственно, проблем. Для записи в бета-тестеры продукта VMware vCenter Support Assistant нужно использовать эту ссылку.

Представляем вам очередную статью нового автора VM Guru - Максима Федотенко. В первой части статьи Максима "Рекомендации по защите инфраструктуры виртуальных десктопов, созданных на базе платформы VMware View" было рассказано о сетевой инфраструктуре в контексте безопасности VDI-решения. Во второй статье цикла речь пойдет о некоторых рекомендациях по настройкам серверов и служб технологической инфраструктуры VMware View.

Недавно компания Citrix анонсировала скорую доступность бета-версии решения Citrix Project Accelerator, предназначенного для сайзинга виртуальных ПК на платформе Citrix XenDesktop. Решение, которое придет на смену продукту Desktop Transformation Accelerator, позволит ответить на такие вопросы как "сколько нужно хост-серверов для моих трехсот VDI-пользователей?", "нужно ли использовать  функциональность Hosted Shared desktops?", "сколько IOPS мне нужно от системы хранения?" и т.п.

Project Accelerator будет работать в сложившейся методологии аудита от Citrix: Assess -> Design -> Deploy, однако с улучшенным механизмом сайзинга по аппаратному обеспечению, где результаты будут динамически перестраиваться при каждом новом вводе исходных данных.

Для получения картинки, приведенной выше, Project Accelerator запросит следующие исходные данные о пользователях и их ПК:

• Уровень персонализации
• Уровень безопасности
• Уровень мобильности
• Уровень критичности в случае потери доступа к виртуальному ПК
• Уровень требуемых ресурсов
• Степень сложности используемых приложений
• Требовательность приложений к ресурсам
• Распространенность приложений в инфраструктуре компании

Все это позволит правильно спланировать необходимые аппаратные мощности, подобрать подходящую референсную архитектуру и получить пошаговое руководство для планирования и внедрения. Чтобы записаться в бета-тестеры Project Accelerator, нужно оставить свой email по этой ссылке.

Многие компании для защиты своей виртуальной инфраструктуры VMware vSphere используют продукт vGate R2 (с поддержкой vSphere 5). Мы уже много писали о способах защиты и функциональности продукта для серверов виртуализации и виртуальных машин, исполняющих серверные нагрузки. В этой заметке, мы хотим рассказать о том, какие сертификаты ФСТЭК имеет решение vGate R2, что поможет вашей организации пройти процедуру аттестации или проверки со стороны государственных органов. Кроме того сертификаты на vGate R2 позволят также подтвердить, что вы правильно защищаете персональные данные, обрабатываемые в виртуальных машинах (до 1 класса ПДн включительно).

Действующие сертификаты на vGate R2 представлены в таблице ниже:

Первый сертификат - для старой версии продукта Security Code vGate for VMware Infrastruture, который поддерживал версии vSphere до четвертой, остальные два - на vGate R2, который поддерживает платформу VMware vSphere 5, а также vSphere 4.0 и 4.1.

В отличие от стандартных средств защиты, которые есть в платформе VMware vSphere, продукт vGate R2 позволяет применять системы виртуализации в государственных и частных компаниях с высокими требованиями к безопасности и защите персональных данных. Кроме того, как известно, сертификат ФСТЭК имеет только версия VMware vSphere 4, которая на сегодняшний день уже является устаревшей, а vGate R2 уже давно имеет сертификаты ФСТЭК на vSphere 5.0 (поддержка и сертификация 5.1 на подходе).

Все это нам дает следующую табличку:

Компания Citrix анонсировала превью очередной версии клиентского гипервизора - XenClient 4.5 Technology Preview. Новая версия клиентского гипервизора, ожидаемая в декабре этого года, будет последователем XenClient 4.1, выпущенной в июле. Напомним, что теперь гипервизор XenClient построен на платформе приобретенного компанией Citrix продукта NxTop.

Новые возможности Citrix XenClient 4.5:

• Поддержка новых моделей ультрабуков и 3-го поколения процессоров Intel vPro.
• Поддержка ОС Windows 8 в виртуальных машинах.
• Поддержка мультиязычности интерфейса клиента: English, French, Spanish, German, Italian, Japanese и Simplified Chinese.
• Тэгирование кадров VLAN.
• Возможность синхронизации с внешней сетью с использованием NetScaler, что позволяет внешним пользователям иметь доступ к компоненту Synchronizer для их удаленных инсталляций XenClient.
• Увеличение скорости загрузки на 30%
• Поддержка двух внешних мониторов для док-станций.
• Новая технология отображения картинки, позволяющая настраивать размещение и разрешения отдельных мониторов.
• Поддержка экспорта виртуальных машин.

Кроме того, был выпущен релиз специализированного клиента Citrix XenClient XT3, который предназначен для организаций с очень высокими требованиями к безопасности и изоляции виртуальных машин. Новые возможности Citrix XenClient XT3:

• Компонент Management Synchronizer (Synchronizer XT), который накатывает обновления, удаленно контролирует политики виртуальных машин и работает независимо от остальных компонентов решения.
• Возможность изоляции отдельных физических сетевых интерфейсов путем их назначения конкретным ВМ.
• Software Development Kit (SDK), позволяющий сторонним компаниям разрабатывать решения в концепции сервисных виртуальных модулей (Linux Service VM appliances).
• Поддержка второго и третьего поколений процессоров Intel vPro.
• Улучшения механизмов SSL и SELinux.
• Соответствие требованиям PL3 и PL4 government.

Те, у кого есть действующая подписка на один из продуктов XenClient, XenDesktop Enterprise или XenDesktop Platinum, могут загрузить XenClient 4.5 Technology Preview по этой ссылке.

Не секрет, что продавать программное обеспечение сейчас - дело неблагодарное и низкомаржинальное, когда дело касается небольших сделок. Когда дело касается большой продажи - это, зачастую, лохотрон, потому как у многих вендоров есть пресловутый механизм "регистрации сделок", который уже давно прогнил и воняет как брошенный у деревенской остановки труп. Почему от него воняет? Очень просто - решение по регистрации сделок целиком лежит на аккаунте вендора, который может быть ангажирован со стороны одного из партнеров, который мотивирует первого разными способами, в том числе Чивасом в помпезном баре или квартальными бонусами. Об этом наши западные друзья, конечно же, знают, но закрывают на это глаза - продавать в Загнивающей как-то же надо.

Они-то знают, как тут строится бизнес и вынуждены работать по правилам, несмотря на то, что заставляют заполнять документы типа "Due Diligence Questionnaire", где сказано куда бежать, если заказчик вымогает взятку. Ну да ладно, речь не об этом.

Речь о том, что VMware на днях сделала доступным публично российский прайс-лист. Присядьте или возьмитесь за поручень и посмотрите:

У тех, кто отвечает за русский прайсинг в VMware - голоса в голове. Когда-то его сделали доступным, потом убрали, теперь он снова на арене, но в новом обличье! Давайте для сравнения заглянем в американский прайс:

И цены наших европейских братьев:

Ого-го, что мы видим. Всего-то мы видим воочию, своими собственными глазами, что:

У нас VMware в 2 раза дороже, чем в Америке.

И чуть поменьше, чем в 2 раза - по отношению к Европе. Это вам даже не Apple со своими Айпадами. Вы вот тут возмущались разнице в цене 30%? Теперь встаньте в стойло и кушайте разницу почти в 100%!

С чем же такое связано? Очень просто - прайс, который вы видите на русском сайте VMware - не совсем настоящий. Какой-то креативный человек в VMware решил провернуть инновационную штуку. А именно: повысить рекомендованные цены для пользователей в России, а для партнеров оставить их прежними (они хоть и не американские, но не в 2 раза же выше). Бедненькие партнеры же страдают со своей копеечной маржой. А тут - нате: давайте вместе считать пользователя мудотрясом и зарабатывать.

Скажу вам по секрету, что старая рекомендованная цена для российского пользователя - как и раньше на 30% выше американской. Поэтому мне ничего не остается, как сказать вам, какую цену вам требовать от партнера - прибавить 30% к американскому прайсу. Это будет адекватно. А этим пусть сама VMware пользуется.

P.S. Если вы донесете это до СМИ или напишете в Спортлото - будет хорошо.

Данная статья посвящена аспектам защиты инфраструктуры виртуальных десктопов, построенной на базе программного обеспечения VMware View. На текущий момент у VMware отсутствуют рекомендации по обеспечению защиты инфраструктуры VMware View наподобие Hardening Guide для VMware vSphere. Точнее сказать они есть, но разрозненны и находятся в различных документах. В части 1 статьи попытаемся рассмотреть рекомендации, которые могут предъявляться к сетевой архитектуре инфраструктуры виртуальных ПК.

Недавно компания Cisco анонсировала скорую доступность бета-версии своего виртуального распределенного коммутатора Cisco Nexus 1000V 2.1, который не только получит много новых возможностей, но и будет иметь бесплатное издание - Essential Edition.

Напомним, что на данный момент актуальная версия коммутатора Cisco Nexus 1000V 1.5.2 работает на VMware vSphere 5.1 и с vCloud Director 5.1 и уже имеет поддержку технологии VXLAN:

В октябре этого года компания Cisco планирует добавить следующие возможности в Cisco Nexus 1000V 2.1:

Поддержка TrustSec SXP позволяет сегментировать виртуальный датацентр на несколько зон безопасности, защищенных политиками, по тэгам SGT:

Появится полноценный плагин к vCenter:

Технология vTracker позволит отслеживать различные процессы и события в сети виртуальной инфраструктуры (например, миграции vMotion):

Модули VSM можно разносить по двум датацентрам в конфигурации Active-Passive:

Теперь о различиях платного (Advanced Edition) и бесплатного (Essential Edition) изданий Cisco Nexus 1000V 2.1:

Пользователи Cisco Nexus 1000V с активной подпиской получают версию 2.1 бесплатно, а также компонент VSG (Virtual Security Gateway) в подарок, который больше отдельно не продается (т.е. его нельзя прикрутить к бесплатному изданию):

Виртуальный распределенный коммутатор Cisco Nexus 1000V будет доступен не только для VMware vSphere, но и для платформ Microsoft Hyper-V, Linux Kernel-Based Virtual Machine (KVM), а также Citrix XenServer. Напомним, что в VMware vSphere его можно использовать только совместно с изданием vSphere Enterprise Plus.

Достаточно давно, известный многим Duncan Epping писал о стартапе CloudPhysics, для которого он является техническим эдвайзором, и который выпускает продукт в виде виртуального модуля (Observer Virtual Appliance), систематизирующий информацию о количественных параметрах виртуальной среды VMware vSphere в виде карточек. На основе этих карточек можно составить заключение о существующих проблемах своей инфраструктуры виртуализации:

Для работы продукта потребуется установить OVA-модуль в своем окружении VMware vSphere, а дальше для просмотра параметров карточек можно использовать веб-консоль (для кого-то это может быть проблемой, так как данные посылаются на сервер CloudPhysics, однако они утверждают, что данные полностью обезличены).

Сами карточки формируются на базе опросов пользователей и всяческих голосований, которые проводятся, например, на конференциях VMworld. Вот примеры таких карточек:

Затем лучшие карточки, будучи реализованными технически, попадают в основной интерфейс продукта (при этом для появления новых карточек не обязательно обновлять виртуальный модуль в своей инсталляции).

Помимо этого есть всякие технические детали о виртуальной инфраструктуре, корелляции параметров и необычные метрики. В общем, для больших инсталляций в плане траблшутинга - штука интересная, попробуйте, это пока бесплатно.

На проходящей с 1 по 3 октября конференции Oracle OpenWorld 2012, компания Oracle объявила о запуске собственного решения для получения вычислительных мощностей из публичного облака в аренду - Oracle IaaS.

Напомним, что на данный момент на рынке облачных инфраструктур IaaS представлено можество компаний:

• Amazon AWS - лидер на рынке облачных вычислений, предоставляющий сервисы IaaS на основе гипервизора Xen.
• VMware vCloud на базе платформы VMware vSphere, распространяемый через экосистему партнеров.
• Microsoft Windows Azure - публичное облако Microsoft на основе собственной ветки гипервизора Hyper-V.
• Google Compute Engine - анонсированное недавно публичное облако Google, предназначенное для аренды мощностей под ресурсоемкие вычисления.

Помимо этого есть и куча других IaaS-облаков, построенных на базе различных архитектур и решений. Теперь к этой разношерстной компании решила присоединиться и Oracle, планирующая предоставление виртуальных машин в аренду на базе своих программно-аппаратных платформ Exadata, Exalogic и SuperCluster. Помимо этого, было анонсировано решение для построения частных облаков организаций Oracle Private Cloud. Сама Oracle планирует прямую конкуренцию с Cloud-платформой Amazon AWS.

Интересная особенность Private Cloud - в случае ее развертывания на площадке клиента, Oracle будет управлять и обслуживать ее на базе платы за потребление ресурсов в месяц. То есть, специалисты Oracle будут администрировать ЦОД компании на ее территории.

При этом будет обеспечена совместимость при перемещении виртуальных машин между собственной инфраструктурой и облаком Oracle. Предлагаются также DR-сценарии и решения по заимствованию мощностей в случае отсутствия собственных под решение насущных задач:

Кроме всего этого, Oracle будет продолжать предоставлять сервисы PaaS для разработки и размещения приложений (для своей БД и Java), а также приложения по модели SaaS - CRM, HCM, ERP и другие.

Вот так выглядел Oracle Public Cloud в 2011 году, когда облако IaaS еще не было представлено:

Посмотрим, как это будет выглядеть сейчас - следите за обновлениями cloud.oracle.com. Когда все это будет - неизвестно.

С 3 по 5 октября в Экспоцентре пройдет отраслевая конференция по информационной безопасности INFOBEZ-EXPO 2012, где, конечно же, будут представлены решения российского производителя "Код Безопасности", выпускающего продукт vGate R2 для защиты инфраструктур виртуализации VMware vSphere средствами политик и механизма защиты от НСД.

Компания «Код Безопасности»  представит на выставке новые версии своих продуктов, предназначенных для защиты государственной и коммерческой тайны, персональных данных. Также на выставке будет презентован первый на российском рынке защищенный планшетный компьютер «Континент Т-10», предназначенный для организации безопасного доступа мобильных сотрудников к защищенным ресурсам корпоративной сети.

Ежедневно на стенде компании «Код Безопасности»  в оборудованной презентационной зоне ведущие эксперты компании будут проводить презентации новых продуктов и отвечать на вопросы посетителей выставки об особенностях их применения. Авторы самых интересных вопросов на каждой презентации получат сувениры с фирменной символикой компании «Код Безопасности».

3 октября 2012 г

• 11:30-12:00 Новые возможности Secret Net 7
• 14:00-14:30 Защита информации в виртуальных средах при помощи vGate R2
• 16:00-16:30 Новые возможности TrustAccess 1.3

4 октября 2012

• 12:00-12:30 Новые возможности TrustAccess 1.3
• 14:00-14:30 Новые возможности Secret Net 7
• 15:30-16:00 Защита информации в виртуальных средах при помощи vGate R2

5 октября 2012

• 11:00-11:30 Защита информации в виртуальных средах при помощи vGate R2
• 13:00-13:30 Новые возможности Secret Net 7

Приглашаем вас посетить стенд компании «Код Безопасности» № 1-200 и принять участие в мероприятиях, организованных компанией для посетителей выставки INFOBEZ-EXPO 2012. Участие в конференции - бесплатное.

Мы уже много писали о сравнении платформ виртуализации VMware vSphere с Microsoft Hyper-V в ОС Windows Server. Когда гипервизор Hyper-V был еще второй версии - безусловно, все такие сравнения выигрывала VMware, кроме вот таких - весьма глупых по своей сути.

Однако с выходом Hyper-V 3.0 в Windows Server 2012 ситуация существенно изменилась - по многим возможностям инфраструктура Microsoft Hyper-V + SC VMM 2012 сравнялась с VMware vSphere 5.1, а где-то даже стала превосходить последнюю. VMware было нечем особенно отвечать на такие сравнения - по цене платформа vSphere сейчас однозначно проигрывает продуктам Microsoft (что очень важно для СМБ), поэтому VMware решила сосредоточиться на традиционной сказке: "большинство затрат - операционные, и мы их экономим больше, чем Microsoft".

В итоге, поняв, что надо как-то отбиваться от маркетинговых вбросов Microsoft, весной компания VMware обратилась к известным каталам сферы виртуализации - компании Principled Technologies, которая сваяла в начале года очередной отчет "Total Cost Comparison: VMware vSphere vs. Microsoft Hyper-V", где vSphere 5 сравнивалась с Hyper-V в ключе затрат на администрирование инфраструктуры:

Этот отчет интересен, прежде всего тем, что в нем много внимание уделено различным типам операций в виртуальной инфраструктуре, которые требовали много времени в Hyper-V R2, наример, Quick Storage Migration:

Теперь такого с Hyper-V не провернешь - там есть и горячая миграция хранилищ, и прочие интересные вещи. Однако сам отчет почитать стоит, чтобы понять тот малый объем юзкейсов для СМБ, в котором инфраструктура VMware сэкономит деньги по сравнению с Microsoft.

Теперь обратим взор к свежей презентации "The VMware Advantage Over Hyper-V 3", сделанной 4 сентября этого года.

Посмотрим, что нам там пытается впарить VMware в ответ на это. Много поддерживаемых ОС - это хорошо:

А вот, что касается функционала (кликабельно):

По-сути, Hyper-V 3 обвиняется в двух основных грехах - слабая подсистема безопасности и отсутствие некоторых Enterprise-возможностей для работы с виртуальными машинами и хранилищами, такими как Storage DRS, SIOC, Auto Deploy и Host Profiles - все эти вещи есть только в издании Enterprise Plus, которое в разы дороже соответсвующего количества лицензий SC VMM и других необходимых компонентов System Center для построения виртуальной инфраструктуры на Hyper-V. Кроме того, нужность всех этих вещей для СМБ - под большим вопросом.

Опять идет неубедительный FUD про долгие операции в Hyper-V и быстрые в vSphere:

Ну и традиционное полотно про превосходство добра над злом:

Большинство из того, что здесь написано - это либо субъективное мнение VMware, либо Enterprise-возможности из дорогущего издания Enterprise Plus. Поэтому, это еще один способ убедиться, что VMware работает на Enterprise, не уделяя рынку СМБ должного внимания, в котором Microsoft в ближайшее время может перетянуть очень большое количество клиентов.

Мы уже писали о том, что такое и как работает технология VMware vStorage API for Array Integration (VAAI) (а также немного тут), которая позволяет передать операции по работе с хранилищами, которые выполняет компонент Data Mover в VMkernel, на сторону дискового массива. Это существенно улучшает показатели производительности различных операций (клонирования и развертывания ВМ, использования блокировок) за счет того, что они выполняются самим массивом, без задействования сервера VMware ESXi:

Если ваш массив не поддерживает примитивы VAAI, то чтобы склонировать виртуальный диск VMDK размером 64 ГБ, компонент Data Mover реализует эту операцию следующим образом:

• Разделяет диск 64 ГБ на малые порции размером в 32 МБ.
• Эту порцию 32 МБ Data Mover разделяет еще на маленькие операции ввода-вывода (I/O) размером в 64 КБ, которые идут в 32 параллельных потока одновремнно.
• Соответственно, чтобы передать 32 МБ, Data Mover выполняет 512 операций ввода вывода (I/Os) по 64 КБ.

Если же массив поддерживает примитив XCOPY (он же Hardware Offloaded Copy и SAN Data Copy Offloading), то для передачи тех же 32 МБ будут использованы I/O размером в 4 МБ, а таких I/O будет, соответственно, всего 8 штук - разница очевидна.

Интересно, как работает VAAI с точки зрения ошибок при передаче данных: например, мы делаем клонирование ВМ на массиве с поддержкой VAAI, и вдруг возникает какая-то ошибка. В этом случае VMkernel Data Mover подхватывает операцию клонирования с того места, где VAAI вызвал ошибку, и производит "доклонирование" виртуальной машины. Далее ESXi периодически будет пробовать снова использовать VAAI на случай, если это была кратковременная ошибка массива.

При этом проверки в разных версиях ESXi будут производиться по-разному:

• Для ESX/ESXi 4.1 проверка будет производиться каждые 512 ГБ передаваемых данных. Посмотреть этот параметр можно следующей командой:

# esxcfg-advcfg -g /DataMover/HardwareAcceleratedMoveFrequency
Value of HardwareAcceleratedMoveFrequency is 16384

Это значение частоты 16384 нужно умножить на порцию 32 МБ и мы получим 512 ГБ. Чтобы поменять эту частоту, можно использовать команду:

# esxcfg-advcfg -s <новое значение> /DataMover/HardwareAcceleratedMoveFrequency

• Для ESXi 5.0 и выше все проще - проверка производится каждые 5 минут.

Помимо описанных в нашей статье примитивов Full Copy, Zero Block и ATS, начиная с версии ESXi 5.0, поддерживаются еще 2 примитива:

• Thin Provisioning - механизм сообщения хостом ESXi дисковому массиву о том, что виртуальная машина или ее файлы с Thin LUN были удалены или перемещены (в силу разных причин - Storage vMotion, консолидация снапшотов и так далее), поэтому массив может забрать это дисковое пространство себе назад.
• Block Delete (UNMAP) - собственно, сам механизм забирания массивом назад дискового пространства через функции SCSI Unmap. Поддерживается с vSphere 5.0 Update 1, так как раньше с этим примитивом были проблемы. Более подробно об этом механизме можно прочитать в KB 2014849, а также в статье "VAAI Thin Provisioning Block Reclaim/UNMAP In Action".

С точки зрения дисковых массивов, работающих на NFS (прежде всего, NetApp) в ESXi 5.0 также появилась поддержка примитивов VAAI:

• Full File Clone – аналог функций Full Copy для VAAI на блочных хранилищах, предназначен для клонирования файлов виртуальных дисков VMDK.
• Native Snapshot Support – передача на сторону массива функций создания снапшота ВМ.
• Extended Statistics – включает возможность просмотра информации об использовании дискового пространства на NAS-хранилище, что полезно для Thin Provisioning.
• Reserve Space – включает возможность создания виртуальных дисков типа "thick" (фиксированного размера) на NAS-хранилищах (ранее поддерживались только Thin-диски).

Функции VAAI включены по умолчанию и будут использованы тогда, когда станут доступны (например, при обновлении Firmware дискового массива, которое поддерживает VAAI).

Мы уже не раз писали о различных типах очередей ввода-вывода, присутствующих на различных уровнях в VMware vSphere, в частности, в статье "Глубина очереди (Queue Depth) и адаптивный алгоритм управления очередью в VMware vSphere". Недавно на блогах компании VMware появился хороший пост, упорядочивающий знания об очередях ввода-вывода на различных уровнях виртуальной инфраструктуры.

Если речь идет о виртуальных машинах на сервере VMware ESXi, работающих с дисковым массивом, можно выделить 5 видов очередей:

• GQLEN (Guest Queue) - этот вид очередей включает в себя различные очереди, существующие на уровне гостевой ОС. К нему можно отнести очереди конкретного приложения, очереди драйверов дисковых устройств в гостевой ОС и т.п.
• WQLEN (World Queue/ Per VM Queue) - это очередь, существующая для экземпляра виртуальной машины (с соответствующим World ID), которая ограничивает единовременное число операций ввода-вывода (IOs), передаваемое ей.
• AQLEN (Adapter Queue) - очередь, ограничивающая одновременное количество обрабатываемых на одном HBA-адаптере хоста ESXi команд ввода вывода.
• DQLEN (Device Queue / Per LUN Queue) - это очередь, ограничивающая максимальное количество операций ввода-вывода от хоста ESXi к одному LUN (Datastore).
• SQLEN (Storage Array Queue) - очередь порта дискового массива (Storage Processor, SP)

Эти очереди можно выстроить в иерархию, которая отражает, на каком уровне они вступают в действие:

Очереди GQLEN бывают разные и не относятся к стеку виртуализации VMware ESXi, поэтому мы рассматривать их не будем. Очереди SQLEN мы уже частично касались тут и тут. Если до SP дискового массива со стороны сервера ESX / ESXi используется один активный путь, то глубина очереди целевого порта массива (SQLEN) должна удовлетворять следующему соотношению:

SQLEN>= Q*L

где Q - это глубина очереди на HBA-адаптере, а L - число LUN, обслуживаемых SP системы хранения. Если у нас несколько активных путей к одному SP правую часть неравенства надо еще домножить на P - число путей.

Соответственно, в виртуальной инфраструктуре VMware vSphere у нас несколько хостов имеют доступ к одному LUN через его SP и получается следующее соотношение:

SQLEN>= ESX1 (Q*L*P) + ESX2 (Q*L*P)+ и т.д.

Теперь рассмотрим 3 оставшиеся типа очередей, которые имеют непосредственное отношение к хосту VMware ESXi:

Как мы видим из картинки - очереди на различных уровнях ограничивают число I/O, которые могут быть одновременно обработаны на различных сущностях:

• Длина очереди WQLEN по умолчанию ограничена значением 32, что не позволяет виртуальной машине выполнять более 32-х I/O одновременно.
• Длина очереди AQLEN - ограничена значением 1024, чтобы собирать в себя I/O от всех виртуальных машин хоста.
• Длина очереди DQLEN - ограничена значением 30 или 32, что не позволяет "выедать" одному хосту ESXi с одного хранилища (LUN) более 30-ти или 32-х операций ввода-вывода

Все эти очереди можно посмотреть с помощью esxtop:

Зачем вообще нужны очереди? Очень просто - очередь это естественный способ ограничить использование общего ресурса. То есть одна виртуальная машина не заполонит своими командами ввода-вывода весь HBA-адаптер, а один хост ESXi не съест всю производительность у одного Datastore (LUN), так как ограничен всего 32-мя I/O к нему.

Мы уже писали о функционале Storage I/O Control (SIOC), который позволяет регулировать последний тип очереди, а именно DQLEN, что позволяет корректно распределить нагрузку на СХД между сервисами в виртуальных машинах в соответствии с их параметрами shares (эта функциональность есть только в издании vSphere Enterprise Plus). Механизм Storage IO Control для хостов VMware ESX включается при превышении порога latency для тома VMFS, определяемого пользователем. Однако, стоит помнить, что механизм SIOC действует лишь в пределах максимально определенного значения очереди, то есть по умолчанию не может выйти за пределы 32 IO на LUN от одного хоста.

Для большинства случаев этого достаточно, однако иногда требуется изменить обозначенные выше длины очередей, чтобы удовлетворить требования задач в ВМ, которые генерируют большую нагрузку на подсистему ввода-вывода. Делается это следующими способами:

1. Настройка длины очереди WQLEN.

Значение по умолчанию - 32. Его задание описано в статье KB 1268. В Advanced Settings хоста ESXi нужно определить следующий параметр:

Disk.SchedNumReqOutstanding (DSNRO)

Он глобально определяет, сколько операций ввода-вывода (IOs) может максимально выдать одна виртуальная машина на LUN одновременно. В то же время, он задает это максимальное значение в IOs для всех виртуальных машин на этот LUN от хоста ESXi (это глобальная для него настройка). То есть, если задано значение 32, то все машины могут одновременно выжать 32 IOs, это подтверждается в случае, где 3 машины генерируют по 32 одновременных IO к одному LUN, а реально к LUN идут все те же 32, а не 3*32.

2. Настройка длины очереди AQLEN.

Как правило, этот параметр менять не требуется, потому что дефолтного значения 1024 хватает практически для всех ситуаций. Где его менять, я не знаю, поэтому если знаете вы - можете написать об этом в комментариях.

3. Настройка длины очереди DQLEN.

Настройка этого параметра описана в KB 1267 (мы тоже про это писали) - она зависит от модели и драйвера HBA-адаптера (в KB информация актуальна на июнь 2010 года). Она взаимосвязана с настройкой Disk.SchedNumReqOutstanding и, согласно рекомендациям VMware, должна быть эквивалентна ей. Если эти значения различаются, то когда несколько ВМ используют с хоста ESXi один LUN - актуальной длиной очереди считается минимальное из этих значений.

Для отслеживания текущих значений очередей можно использовать утилиту esxtop, как описано в KB 1027901.

Для тех, кто активно использует инфраструктуру виртуальных ПК на базе решения VMware View, на сайте проекта VMware Labs появился интересный скрипт - View Controlled Recompose Script. Как знают пользователи VMware View, при необходимости обновления десктопов можно сделать операцию "Recompose", где, выбрав обновленный снапшот базовой ВМ или другую базовую ВМ, можно перестроить виртуальные машины пользователей пула ПК на работу с новым диском, не затрагивая диск с пользовательскими данными:

В отличие от стандартых средств по рекомпозиции в VMware View Manager, в скрипте View Controlled Recompose производится интеллектуальная процедура: через интерфейс WMI производится определение неиспользуемых виртуальных машин, после чего один из таких десктопов используется как реплика (Replica VM), а далее для неиспользуемых десктопов происходит рекомпозиция на базе этой реплики. Потом для активных десктопов можно сделать Force Logoff и перенаправить пользователей на уже рекомпозированные виртуальные ПК, а для этих активных десктопов, в свою очередь, доделать рекомпозицию.

По умолчанию скрипт работает в интерактивном режиме и принимает следующие входные параметры:

• Pool - пул виртуальных ПК для рекомпозиции
• ParentVM - полный путь к базовому образу
• NewSnapshot - полный путь к снапшоту образа, из которого будет создаваться реплика и делаться рекомпозиция

Скрипт необходимо запускать на сервере VMware View Connection Server, сам же скрипт сделан на PowerCLI / PowerShell. Более подробные инструкции по его использованию приведены по этой ссылке.

Скачать скрипт VMware View Controlled Recompose Script можно по этой ссылке.

Виктор прислал мне презентацию от того самого Ивана, который на одной из юзер-групп VMware рассматривал особенности дизайна и проектирования виртуальной инфраструктуры VMware vSphere. Часть, касающаяся виртуализации различных типов нагрузок в гостевых ОС виртуальных машин показалась мне очень интересной, поэтому я решил перевести ее и дополнить своими комментариями и ссылками. Итак, что следует учитывать при переносе и развертывании различных приложений в виртуальных машинах на платформе vSphere.

На прошедшей конференции Google I/O 2012 было анонсировано много чего интересного: Android 4.1 Jelly Bean, планшет Nexus 7, медиаплеер Nexus Q, приняты предварительные заказы на Project Glass для разработчиков, анонсировано расширение магазина Google Play и прочее.

Но нас с вами интересует, конечно же, не это. Главная для нас новость - это анонс нового публичного IaaS-облака от интернет-гиганта, которое называется Google Compute Engine. На конференции было продемонстрировано приложение по обсчету генома, запущенное в кластере из 1250 виртуальных машин (у каждой 8 ядер) на этой платформе, что, возможно, намекает на направленность Google на сегмент "Big Data", а также научные и исследовательские задачи крупных компаний и университетов.

Google Compute Engine - это новый сервис аренды вычислительных сред в публичном облаке (IaaS) на базе ОС Linux, предоставляющий услуги на базе платы за почасовое потребление ресурсов (вычислительные мощности и хранилища). Поддержки Windows в данных вычислительных средах пока не заявлено. Напомним, что у Google уже есть PaaS-платформа App Engine и сервис облачного хранения Cloud Storage. Сам сервис Compute Engine (CE) доступен для пробного использования только по приглашениям (Limited Preview).

Таким образом, мы получаем трех потенциальных лидеров рынка IaaS-сервисов из публичного облака: старейший Amazon AWS, анонсированный в начале июня Microsoft Windows Azure и Google Compute Engine. Особняком стоит компания VMware, предоставляющая решения VMware vCloud, на базе которых любой сервис-провайдер может построить публичное облако. При этом VMware не скрывает своей направленности исключительно на крупный корпоративный сектор (сейчас существует около 125 сертифицированных публичных облаков vCloud от партеров VMware по программе VSPP в 26 странах, которые предлагают аренду виртуальных машин). Отметим также и решение Citrix Xen Cloud Platform от компании Citrix и сообщества Xen.

Основные особенности Google Compute Engine:

• Вычислительные среды. Доступны в конфигурации 1,2,4 или 8 ядер на Linux-платформе с 3,75 ГБ оперативной памяти на одно ядро.
• Хранилища. Можно хранить данные виртуальных машин в виде непостоянных (Ephemeral), а также постоянных (Persistent) дисков на стороне Google или в сервисе Google Cloud Storage. Для постоянных дисков можно делать снапшоты в целях резервного копирования, а также предоставлять доступ к одному диску со стороны нескольких ВМ. Все данные дисков шифруются.
• Сетевое взаимодействие. Возможность использовать высокопроизводительное сетевое оборудование датацетров Google и самостоятельно конфигурировать сетевые экраны, также использовать внешний IP-адрес. Плюс готовые решения от сторонних вендоров, которые выступают партнерами Google.
• Управление. Виртуальными машинами можно будет управлять через веб-консоль или CLI, также есть API, предоставляющий множество возможностей разработчикам и сторонним производителям.

Google Compute Engine будет интегрирован с партнерскими решениями RightScale, Puppet Labs,OpsCode, Numerate, Cliqr, MapR и другими.

Безусловно, Google вступает на рынок IaaS-решений довольно поздно. Но это только одна сторона медали - на самом деле, более 90% компаний вообще еще не пользовались облачными ресурсами уровня IaaS, поэтому потенциал рынка огромный. Также отметим возможную "нишевость" сервиса от Google, если он будет направлен на высокопроизводительные вычисления по цене существенно меньшей, чем у конкурентов.

Кстати, о цене. Заявленные цены выглядят так:

Значение GCEU (Google Compute Engine Units), которое вы видите в правой колонке - это аналог Amazon EC2 Compute Unit (как написано тут), т.е. где-то эквивалент 1.0-1.2 ГГц на процессорах 2007 Opteron or 2007 Xeon.

Также на сайте thenextweb.com проведено сравнение анонсированных цен на Google Compute Engine и уже объявленных Microsoft на Windows Azure. По расчетам получается, что при где-то одинаковой цене мощностей Google Compute Engine и Windows Azure, сервис от Google дает на 50% больше оперативной памяти для ВМ.

Мы уже недавно писали о метриках производительности хранилищ в среде VMware vSphere, которые можно получить с помощью команды esxtop. Сегодня мы продолжим развивать эту тему и поговорим об общей производительности дисковых устройств и сайзинге нагрузок виртуальных машин по хранилищам в виртуальной среде.

Как говорит нам вторая статья блога VMware о хранилищах, есть несколько причин, по которым может падать производительность подсистемы ввода-вывода виртуальных машин:

• Неправильный сайзинг хранилищ для задач ВМ, вследствие чего хранилища не выдерживают такого количества операций, и все начинает тормозить. Это самый частый случай.
• Перегрузка очереди ввода-вывода со стороны хост-сервера.
• Достижение предела полосы пропускания между хостом и хранилищем.
• Высокая загрузка CPU хост-сервера.
• Проблемы с драйверами хранилищ на уровне гостевой ОС.
• Некорректно настроенные приложения.

Из всего этого набора причин самой актуальной оказывается, как правило, первая. Это происходит вследствие того, что администраторы очень часто делают сайзинг хранилищ для задач в ВМ, учитывая их требования только к занимаемому пространству, но не учитывая реальных требований систем к вводу выводу. Это верно в Enterprise-среде, когда у вас есть хранилища вроде HDS VSP с практически "несъедаемой" производительностью, но неверно для Low и Midrange массивов в небольших организациях.

Поэтому профилирование нагрузки по хранилищам - одна из основных задач администраторов VMware vSphere. Здесь VMware предлагает описывать модель нагрузки прикладной системы следующими параметрами:

• Размер запроса ввода-вывода (I/O Size)
• Процент обращений на чтение (Read)
• Процент случайных обращений (Random)

Таким образом профиль приложения для "типичной" нагрузки может выглядеть наподобие:

8KB I/O size, 80% Random, 80% Read

Само собой, для каждого приложения типа Exchange или СУБД может быть свой профиль нагрузки, отличающийся от типичного. Размер запроса ввода-вывода (I/O Size) также зависит от специфики приложения, и о том, как регулировать его максимальное значение на уровне гипервизора ESXi, рассказано в KB 1008205. Нужно просто в Advanced Settings выставить значение Disk.DiskMaxIOSize (значение в килобайтах). Некоторые массивы испытывают проблемы с производительностью, когда размер запроса ввода-вывода очень велик, поэтому здесь нужно обратиться к документации производителя массива. Если с помощью указанной настройки ограничить размер запроса ввода-вывода, то они будут разбиваться на маленькие подзапросы, что может привести к увеличению производительности подсистемы ввода-вывода на некоторых системах хранения. По умолчанию установлено максимальное значение в 32 МБ, что является достаточно большим (некоторые массивы начинают испытывать проблемы при запросах более 128 KB, 256 KB или 512KB, в зависимости от модели и конфигурации).

Однако вернемся к профилированию нагрузок по хранилищам в VMware vSphere. В одной из презентаций VMware есть замечательная картинка, отражающая численные характеристики производительности дисковых устройств в пересчете на шпиндель в зависимости от типа их организации в RAID-массивы:

Параметры в верхней части приведены для операций 100%-й последовательной записи для дисков на 15К оборотов. А в нижней части приведены параметры производительности для описанной выше "типичной" нагрузки, включая среднюю скорость чтения-записи, число операций ввода-вывода в секунду (IOPS) и среднюю задержку. Хорошая напоминалка, между прочим.

Теперь как анализировать нагрузку по вводу выводу. Для этого у VMware на сайте проекта VMware Labs есть специальная утилита I/O Analyzer, про которую мы уже писали вот тут. Она может многое из того, что потребуется для профилирования нагрузок по хранилищам.

Ну а дальше стандартные процедуры - балансировка нагрузки по путям, сторадж-процессорам (SP) и дисковым устройствам. Сигналом к изысканиям должен послужить счетчик Device Latency (DAVG) в esxtop, если его значение превышает 20-30 мс для виртуальной машины.

Мы уже давно писали о новых возможностях продукта номер 1 для защиты виртуальных инфраструктур - vGate R2 с поддержкой VMware vSphere 5, а также о получении им всех необходимых сертификатов ФСТЭК. Теперь же новые версии продуктов vGate R2 и vGate S R2 официально поступили в продажу и доступны для заказа у партнеров компании Код Безопасности.

Среди основных возможностей новой версии продукта:

• Полная поддержка VMware vSphere 5
• Новый интерфейс просмотра отчетов. Для построения отчетов больше не требуется наличие SQL-сервера, устанавливаемого ранее отдельно.
• Поддержка новых стандартов и лучших практик в политиках и шаблонах (VMware Security Hardening 4.1, PCI DSS 2.0, CIS VMware ESX Server Benchmark 4).
• Поддержка распределенного коммутатора (Distributed vSwitch) Cisco Nexus 1000v.
• Поддержка 64-битных систем в качестве платформы для vGate Server.
• Улучшение юзабилити, пользовательного интерфейса и масштабируемости.
• Поддержка альтернативного метода лицензирования на базе платы за виртуальную машину за месяц (по модели SaaS).

Из официального пресс-релиза компании Код Безопасности:

Компания «Код Безопасности» сообщает о передаче в продажу новых версий сертифицированного программного продуктаvGate R2/ vGate S R2, предназначенного для защиты от НСД систем управления виртуализированных инфраструктур, построенных на платформах VMware. Новые версии продуктов доступны для приобретения с начала мая 2012 года.

Новые сертифицированные версии vGate R2/ vGate S R2 содержат ряд значительных улучшений и функциональных модернизаций, которые позволяют наиболее полно решать задачи компаний по обеспечению безопасности информации, обрабатываемой и хранящейся в инфраструктурах, построенных на платформах VMware.

В частности, добавлена возможность поддержки инфраструктур виртуализации, распределенных по нескольким подсетям. Также в новых сертифицированных версиях для удобства работы администраторов улучшены возможности фильтрации списков защищаемых объектов: теперь фильтрация может производиться по объектам (ВМ, сервер и др.).

Улучшены возможности работы с отчетами аудита – теперь возможна фильтрация по описанию событий.

Значительно улучшен конфигуратор продукта, который в новых версиях запускается сразу после установки и позволяет сделать необходимые настройки продукта таким образом, чтобы можно было начать его использование непосредственно после установки.

Относительно поддержки аппаратных средств в новых версиях vGate R2/ vGate S R2 теперь предусмотрена поддержка работы с Distributed vSwitch Cisco Nexus 1000v. Улучшения коснулись и шаблонов автоматического приведения систем в соответствие с требованиями лучших практик и стандартов. Теперь с помощью vGate R2/ vGate S R2 можно автоматизировать привидение систем в соответствие с требованиями следующих лучших документов:

• vSphere 4.1 Security Hardening Guide,
• CIS Security Configuration Benchmark for VMWare ESX 4 v. 1.0,
• PCI DSS версия 2.0.

По-прежнему компаниям-пользователям остаются доступны шаблоны автоматического приведения систем в соответствие с ФЗ-152 и СТО БР ИББС.

Пробную версию продукта vGate R2 можно скачать бесплатно по этой ссылке.

Одновременно с выпуском новой версии решения для виртуализации настольных ПК предприятия VMware View 5.1 компания VMware выпустила также средство централизованного мониторинга и поддержки жизнеспособности инфраструктуры VDI - vCenter Operations Manager for VMware View (см. предыдущие новости о vCenter Operations тут).

Как мы видим из дэшборда, приведенного на картинке, средство vCenter Operations Manager имеет множество относящихся именно к VMware View метрик и индикаторов (сессии, клиенты, PCoIP). В целом, продукт сфокусирован на отслеживании производительности объектов VDI-инфраструктуры, мониторинге их жизнедеятельности и определении узких мест и источников проблем.

Интересной особенностью VMware vCenter Operations Manager for View является то, что продукт не имеет каких-то предопределенных пороговых значений или дефолтных настроек, которые позволяют определить, все ли в порядке с вашей инфраструктурой. Он запоминает нормальные показатели в процессе мониторинга, а потом сигнализирует о существенных отклонениях от них. Эти показатели наблюдаются в рамках динамических пороговых значений, которые определяются на основе интеллектуального алгоритма.

Вот, например, мы видим, что количество PCoIP-пакетов для десктопа выше обычного:

vCenter Operations Manager для VMware View пропагандирует концепцию "мониторьте все, исправляйте только то, где есть проблемы". Определить, что сломалось поможет цветовое кодирование объектов при "проваливании" в них по иерархии (красный обозначает проблему):

Все это показывается в виде условных очков (видим, что сторадж барахлит):

Далее, идя вниз по иерархии, доходим до производительности конкретных устройств, где vCenter Operations Manager for View показывает признаки проблем (увеличилась latency для чтения и записи):

Ну а на следующем графике мы видим, что все это из-за резкого увеличения числа виртуальных машин:

То есть, vCenter Operations Manager for View позволяет выявлять проблемы на различных уровнях инфраструктуры VDI и выяснять, что именно явилось их причиной. Делается это средствами встроенной базы знаний, в которой заложены зависимости между различными отслеживаемыми метриками в виртуальной среде VMware View.

Также интересно видео, где пользователь звонит в техподдержку и говорит: "мой комп тормозит, в чем дело?". Далее администратор vCenter Operations ищет пользователя в консоли и выясняет, что стряслось с компонентами его десктопа:

Остальные видео тут, а страница продукта vCenter Operations Manager for View находится здесь.

22 мая компания VMware объявила о достижении соглашения по приобретению компании Wanova Mirage, которая занимается поставкой решений для управления образами пользовательских сред в корпоративной ИТ-инфраструктуре.

Если посмотреть на демо-видео от Wanova, то можно понять, что это решение, которое позволяет создать образ рабочей станции пользователя, разделив его на слои (система, приложения, а также данные и настройки пользователя), а потом централизованно управлять такими образами с двух сторон: обновления, резервное копирование, политики и настройки со стороны системного администратора, а также внесение изменений в данные и настройки ПК со стороны пользователя. Работает это все за счет агентов установленных на конечные устройства, обслуживающих кэширование данных и и их двунаправленную синхронизацию, а также управление слоями в целях обновлений, восстановления из бэкапов и т.п.

То есть, это решение для централизации управления и доставки образов ПК на традиционные компьютеры и ноутбуки. Отметим, что VMware приобрела решение Wanova не только с прицелом на виртуальную, но и на физическую среду. Напомним также, что у VMware есть и свое решение для выделения пользовательского слоя в виртуальную сущность - View Persona Management.

С точки зрения виртуальной среды, этот слоистый образ будет называться Centralized Virtual Desktop (CVD). Уже есть мысли по поводу того, как использовать такую концепцию для VMware View и локальных копий виртуальных ПК, которые на стороне клиентов исполняются в VMware Fusion:

То есть такой "сборный десктоп" можно доставлять в физические и виртуальные машины, работающие на различных платформах, в частности, VMware View Local Mode. При этом VMware View и Wanova могут работать как независимо, так и совместно. Например, в случае совместного использования, View отвечает за исполнение ПК на хост-серверах и их доставку на тонкие клиенты, планшеты и нетбуки, а Wanova за управление и доставку образов в физические и виртуальных ПК и ноутбуки, а также передачу образов в виртуальные машины VMware View при взаимодействии с View Composer. Эта концепция будет удобна также и для тех ПК, которые используются разъездными или филиальными работниками без подключения к интернету (на физической или виртуальной платформе).

В конечном итоге, приобретение наработок Wanova даст компании VMware следующие преимущества в сфере end user compiting:

• Возможность централизованного управления образами физических и виртуальных ПК из одного решения (конфигурация, обновления, безопасность и т.п.).
• Реализация сложных сценариев миграции, например, с Windows XP на Windows 7, где необходимо обновить ОС, оставить приложения, настройки и данные пользователей, а часть десктопов перенести в виртуальную среду на VMware View.
• Централизованное резервное копирование и быстрое восстановление данных виртуальных и физических ПК. Отсутствие необходимости больших объемов для хранения бэкапов (хранятся только оригинальные данные).

На словах все это выглядит красиво, хотя VMware придется серьезно поработать, чтобы сделать администрирование этой штуки простым и без многоконсольности. Но это у них и раньше вроде неплохо получалось.

Вы уже, наверняка, читали про новые возможности VMware View 5.1, а на днях обновился калькулятор VDI Flash Calculator до версии 2.8, предназначенный для расчета вычислительных мощностей и хранилищ, поддерживающий новые функции платформы виртуализации настольных ПК.

Среди новых возможностей калькулятора VDI:

• Поддержка VMware View 5.1
• Поддержка функции VMware View CBRC для системного диска (Content Based Read Cache) - предполагается уменьшение интенсивности ввода-вывода на чтение на 65%
• Поддержка связанных клонов на томах NFS для кластеров vSphere, состоящих из более чем 8-ми хостов
• Поддержка платформ с высокой плотностью размещения виртуальных ПК
• Поддержка разрешения экрана 2560×1600
• Небольшие изменения в интерфейсе

Ну и небольшое обзорное видео работы с калькулятором: